


Vehicle Diagnostics 
Adapter (2) 


Windows software for the OBD-2 interface 


Design by G. Muller 


In the previous article we described the hardware necessary to enable a vehicle 


OBD system to communicate through the serial port of a PC. As we mentioned 


you can use a terminal emulator program to read this ASCII coded data or 


better still try this free Windows program, it not only allows you to talk with 


the vehicle in a more user-friendly fashion, it also interprets the ‘trouble codes’. 


Vehicle OBD systems only understand and 
speak using hexadecimal characters. If you 
are not equipped with a reference book 
detailing the OBD protocols it is difficult to 
make any meaningful communication with an 
OBD system with just a terminal emulator 
program to help you. What we need is a 
user-interface program that converts OBD-2 
data into a readable format and likewise con- 
verts user commands into OBD-2 messages. 
It would also be helpful if the program could 
output a description of the detected fault and 
suggest possible causes of the problem with- 
out the user needing to refer back to a list of 
codes or the vehicle handbook. 

The ELM interpreter chip described in 
detail in the previous article is a dedicated 
pre-programmed microcontroller designed to 
perform low-level communications with the 
vehicle OBD system. It handles the OBD ini- 
tialisation by sending hex value 0x33 at 5 
baud via the L pin on the connector (pin 15). 
More recent vehicles use the K pin (pin 7). 
When the ELM chip receives the response 
(hex value 0x55 at 10400 baud) it will know 
that initialisation was successful. After ini- 
tialisation it continually sends dummy char- 
acters every five seconds to keep the com- 
munication link active. The chip also performs 
calculations necessary to check the Cyclic 
Redundancy Check (CRC) checksum 
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Figure |. Main menu of the Scantool.net OBD-2 diagnostic program. 








Display current 
sensor data (RPM, 
Engine Load, Coolant 
Temperature, Speed, 
etc.) 








appended to the OBD data, thereby 
reducing the possibility of data 
being corrupted. 

As we detailed in the first article 
in this series, faults or failures found 


by the diagnostic system are given 
an identifying code number. In the 
OBD-2 literature these are referred to 
as ‘trouble codes’. Using the infor- 
mation given describing the OBD-2 
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Figure 2. The settings available under 
‘options’. 





protocol together with the communi- 
cations of the ELM interpreter chip 
covered in previous articles (see ‘Lit- 
erature’ at the end of this article) it 
is now possible to outline some 
basic functional blocks of a PC based 
program that will usefully interface 
with the OBD system: 

— Read out and clear ‘trouble codes’. 

— Read out and display sensor read- 
ings in real time. 

— Read out freeze-frame data. 

— Read out test results produced by 
the vehicle on-board electronics 
system. 

— Read out vehicle manufacturer spe- 
cific information. This is only avail- 
able on vehicles manufactured 
more recently and includes infor- 
mation such as the Vehicle Identi- 
fication Number (VIN). 


Free Windows Software 


A Windows program fulfilling these 
requirements has been developed by 
ScanTool.net (Wwww.scantool. net). 
The program is called ScanTool (Fig- 
ure 1) and is currently available as 
release 1.04 (beta). The program is 
available as ‘open source’ software 
so that all the necessary source code 
is freely available to ensure that 
porting to operating systems other 
than Windows is a relatively pain- 
less process. Earlier releases of 
ScanTool operate in a DOS environ- 
ment and can be run in a DOS win- 
dow in Windows but the more recent 
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releases of Windows (2000, NT and 
XP) do not support this feature and 
do not allow low-level access to the 
ports and display hardware. Run- 
ning the DOS version of ScanTool 
under these operating systems 
means that it is necessary to 
power-up or reset the PC with a DOS 
boot disk in the floppy drive and 
then start the program using DOS 
commands. The latest release of 
ScanTool (version 1.04) however 
works in a Windows environment. 
All software and source code can be 
downloaded from this month’s Free 
Downloads page of the Elektor Elec- 
tronics website at www.elektor- 
electronics.co.uk — go to Free 
Downloads and click on the informa- 
tion for December 2002. 

In the spirit of open-source soft- 
ware, the source code includes a 
readme file containing information of 
the compilation process together 
with details of the open-source com- 
piler program and Allegro user-inter- 
face libraries so that you can experi- 
ment by adding your own features 
and develop the software (and your 
programming skills) further. The 
software team at ScanTools have 
invested much time and effort in pro- 
ducing this useful program. 

Those of you who do not feel con- 
fident enough to tackle the software 
can periodically check the web site 
for forthcoming updates to the 
ScanTool software. 


Program functions 


Version 1.4 of the ScanTool program 
can read and reset OBD trouble 
codes and also display up to 11 sen- 
sor readings in real time. Additional 
features such as displaying freeze- 
frame data (sensor values stored at 
the time the trouble occurred) and 
support for various test modes 
appear in the main menu of the user 
interface but are not yet imple- 
mented in this beta version of the 
software. Also not yet implemented 
is a method of storing data output 
from the system. In the DOS version 
of the program the key sequence of 
Ctrl + Alt + Print will generate a file 
in the current directory with the 
name screenshotX.pcx contain- 
ing a screenshot where ‘X’ is a inte- 
ger incremented each time the 
screenshot is taken. In the Windows 


version pressing ‘print screen’ will copy the 
screen to a buffer so that it can be pasted toa 
document later. 

Reading either the codes or sensor data 
will only work if the connections between the 
PC, interface adapter and OBD-2 connector 
are correctly made and the vehicle ignition is 
switched to ‘ON’. If these conditions are not 
met you will see a message asking you to 
check the serial port settings. The ‘option’ 
button (Figure 2) allows the measurement 
system to be switched between metric or US 
(imperial) units. This setting is stored in the 
scantool.cfg file along with the on/off set- 
ting for each of the 11 sensor inputs. Fault 
messages including software failures are 
logged in the log.txt file. 

The two data files codes.dat and 
scantool.dat must be in the same direc- 
tory as the scantool.exe program so that 
they can be used when the program starts. 
The file codes .dat contains a description for 
the 3107 trouble codes including all the stan- 
dard codes together with many additional 
manufacturer specific codes. In the ‘Read 
Codes’ page there is an option to simulate 
troubles (Figure 3) and produce the corre- 
sponding comments related to the type of 
trouble. To read the actual trouble codes, 
press the ‘Read’ button, a fail indicator will 
be associated with each trouble code. The 
‘Clear’ button will erase all the trouble codes 
but only after answering yes to the ‘are you 
sure?’ dialog box. The key for the alphanu- 
meric trouble codes are given in the previous 
article and can also be found on many Internet 
sites, some of which are mentioned at the 
end of this article. The description corre- 
sponding to each code is mainly self-explana- 
tory like the description of the sensors in the 
sensor data screen (Figure 4). One exception 
to this is the ‘injector status’ that actually 
refers to the catalyst control loop and the sta- 
tus can be OPEN LOOP or CLOSED LOOP 
along with some error conditions. One task of 
the engine ECU is to ensure that the catalyst 
in the catalytic converter is operating at opti- 
mal efficiency. An oxygen (lambda) sensor is 
used to measure the amount of O, in the 
exhaust and the engine ECU uses this mea- 
surement to adjust the fuel/air mix. When the 
engine is first started the temperature of the 
lambda sensor is too low to give any mean- 
ingful output so the control loop is said to be 
in an open-loop condition. The loop becomes 
closed once the lambda sensor has reached 
its working temperature. An increasing num- 
ber of lambda sensors are fitted with heaters 
to reduce the warm-up time. 

The file scantool.dat contains bitmaps 
for the program graphics, buttons, colour pal- 
let and fonts. It is anticipated that a separate 
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file will eventually be generated to contain 
the text strings (currently in the main pro- 
gram) used in the program. This will make it 
easier to change the text so that the program 
can be used in other countries. Both of the 
files with the .dat extension are in a packed 
format and allow the Allegro ‘Grabber’ tool to 
be used. With this system it will, for example, 
be possible to alter the text and add new tips 
in the ‘Possible causes and known solutions’ 
box without re-compiling the software. 

Further advice on modifying the program 
— or indeed writing a completely new pro- 
gram — is beyond the scope of this article. 
The ScanTool program is well designed with 
good modularity and appropriate comments 
so that even a weekend programmer should 
find it easy to make successful modifications 
to the source code. A quick trawl of the Inter- 
net will produce many sites with information 
supporting the OBD-2 standard. 

The development of the ScanTool program 
is an ongoing process so that we can expect to 
see the missing features implemented soon 
and possibly even a version running under 
Linux. Any modifications that you make to 
the source code must be carried out in accor- 
dance with the rules of the GNU general pub- 
lic licence for free software if you intend the 
modified program to be publicly distributed. 


Putting it into practice 


You would probably expect that vehicle 
repairs would be greatly simplified with an 
OBD system but this is not always the case. 
The more components that a system con- 
tains, the greater the chance of a single item 
failing. It is probably fair to say that the aver- 
age garage mechanic has little time to inves- 
tigate causes of a reported sensor failure and 
would always choose to replace a ‘faulty’ 
sensor. This expense can often be avoided by 
following systematic troubleshooting proce- 
dures at home; simple checks on the wiring 
and connections to the sensor may uncover 
the real culprit. Many of the causes and solu- 
tions suggested for the reported trouble 
codes indicate either a loose cable connection 
or a short circuit either to ground or to the 
vehicle battery (Vbatt) as a possible cause of 
the trouble. Maybe the failure is a result of a 
problem with another component in the vehi- 
cle (e.g., a faulty air flow sensor would cause 
the fuel/air mixture to be incorrectly set 
resulting in a bad exhaust gas lambda read- 
ing). Very often the cost of a workshop manual 
for your vehicle will be repaid many times 
over in saved time and trouble. These manu- 
als approach faultfinding using a logical, 
step-by-step procedure and interpret error 
codes reported via the diagnostics connector. 
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Diagnostic Trouble Code Definition 


B1290 | Oil Temperature Sensor Circuit Short To Ground 


Possible Causes And Known Solutions 
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Figure 3. Trouble code display along with the description. 


Even if you don’t enjoy the prospect 
of getting your hands dirty and prefer 
to entrust repairs to your local 
garage, information gleaned from the 
OBD can be very useful in determin- 
ing the state of health of your vehicle 
and can help you decide any fault 
priority and whether it will harm the 
engine if you continue to use the car 
for work for a few days. Some faults 
such as incorrect ignition timing or 
too lean fuel/air mixture however, 
require immediate attention other- 
wise serious damage will ensue rel- 
atively quickly. In any case, the 
engine ECU will switch to an emer- 
gency mode to help prevent engine 
damage but this settings is not par- 
ticularly fuel-efficient. 

As the motorcar becomes more 
sophisticated we notice that repair 


Scantoo.nct 1.04 


bills are also inevitably rising. 
Armed with a PC we can now plug 
into the vehicle OBD and use this 
increased sophistication to actually 
help reduce vehicle maintenance 
costs. 

(020138-3) 
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[oN] Engine RPM: 695 rom | 


[ ON | Calculated Load Value: 36.1% 





[ ON | Coolant Temperature: 197° F 
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Figure 4. Sensor data page of the Scantool.net program. 


Elektor Electronics 12/2002 


